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Method for Distributing Passwords 

* 

Creation and distribution of end-user passwords for applications and application proxies 
is problematic. On the one hand, end-users tend to create passwords that may be simple, 
5 short and easily figured out by unauthorized parties. On the other hand, finding out the 

relationship between die aid-user identities and their passwords is often insecure and 

costly. 

Even though there are mechanisms that allow the re-use of already existing passwords 
between different trust domains, such as Single-Sign-On solutions developed by Liberty 

10 Alliance, it is often required to relay on a third party to perform the authentication, ia 
this kind of model, the service provider does not actively take part in the authentication. 
On the other hand, the password management performed by the service provider is not 
always appropriate because the handling of passwords in application servers requires 
complex, and costly management ptocedures, e.g. maintenance of the password 

15 lifetimes, overlapping password values, policies regarding valid values, and so on: Also, 
the end-users do not want to remember many passwords, and they tend to use the same 
passwords with several application servers, which clearly decrease the level of security. 

HTTP Digest authentication framework (RFC 2617 and potential extensions) may 
20 include methods that are able to generate end-user passwords. For example, HTTP 
Digest AKA (RFC 3310 and its potential extensions) is a method for creating end-user 
passwords using existing 3GPP authentication infrastructure based on AKA credentials 
stored on tamper-resistant device, the so-called ISIM/USIM/SIM cardL Details can be 
found at http://wWW.ietf.Qfg/rfc.html Even though HTTP Digest provides a flexible 
25 way to generate fresh passwords without user involvement* it does not include a 
standard way to further delegate these passwords to third parties, such as application 
servers or proxies in visited networks. Furthermore, the current standards typically 
assume that the passwords generated using HTTP Digest can only be used once. This 
invention describes how the passwords generated using HTTP Digest AKA can be 
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delegated JO third parties so that the passwords can bs securely used for subsequent 
authentication* 



The initial authentication is done between the end-user device and its home network 
5 using HTTP Digest with algorithm that is able to generate passwords, for example using 
HTTP Digest AKA (RFC 3310 and its potential extensions). During the initial 
authentication, the home network initiates a process in which the new password 
generated during HTTP Digest AKA is linked to the identity of a third party, such as an 
application server or a proxy in the visited network, and to a new temporary end-user 
10 identity for that third party. Hie end-user device and the third party can start using the 
new password and related identities using HTTP Digest (RFC 2617 and its potential 
extensions) as authentication method. 

The solution works in the following way if HTTP Digest AKA is used; 
15 1) the end-user sends a HTTP request to an application server (the third party) that 
does not share password with the end-user, 
2) the challenge is sent to an authentication node in the home network (different 
procedures will apply); the identity of the application server may be included in 
the message; 

20 3) the authenticator authenticates (or helps the application server to authenticate) 
the end-user in the way that the new HTTP Digest AKA password generated 
during the authentication can be used with the application server (third party); 
the identity of the application server (e.g. the "reaJn*") and the identity of the 
end-user in that application server (e.g. the "username") are told to the end-user 

25 device by including this information to the HTTP Digest AKA authentication 

challenge: 

4) the application server (third party) and the end-user device can start using the 
new password and identities when authenticating each other using HTTP Digest 
(RFC 2617). Depending on the implementation, the password can be given to 
30 the application server (third party), or the authenticator can keep the password, 
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and perform the authentication without revealing the password to the application 
server (third party). 

HTTP Digest authentication framework use the following concepts that axe also used in 
5 this document; 

- 'realm': A string by which the client side knows which username and password to 
use. This string should contain at least the name of the host performing the 
authentication and might additionally indicate the collection of users who might 
have access- An example might he registered users©home.com n . In 3GFP/AKA 

10 context, the realm of the home network is typically stored in SIM/USIM/ISIM card. 

- 'username*: The user's name in the specified realm. This string is used in the server 
side the find the correct password for the user. In 3GPP/AKA context, the username 
used with the home network is typically stored in SlM/USIM/ISIM card. In most 
cases, the username is the same as the so-called Private Identity (Bs&PI)l 3GPP 

IS useniaroe identifies the subscription, and for this reason the passwords are sp6dfic 

to the end-user device rather than to the real end-user. Note also that in normal 
HTTP authentication framework, the username and password are typed in by the 
end-user, but in 3GPP/AKA context these fields are automatically filled by end-user 
device. 

20 The system h*$ three entities: 1) the end-user device (UE) with HTTP Digest AKA 
hnplCTientation, 2) application server (AS), and 3) authenticator. 

Step la 



2rt the first phase (see figure Ia) = the UE is initially authenticated using HTTP Digest 
AKA, and the created password is tied to the AS, and UE identities. 
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Figure la: Password generation and identity agreement 
The procedure has the following steps: 

1) UE sends a HTTP request (typically HTTP GET) to an AS. 

2) Since the AS and the UE do not have a shared secret, the AS redirects the request to 
the Authenticator. Before redirecting the request, the AS may define 4 new 
temporary username for the end-user. The AS includes this usemame and its own 
identity information to the request (typically the identity information is encoded into 
the URI parameter in some standard format, e.g. "usemame <§*realm"). How the AS 
knows the identity of the Authenticator is out of the scope of this innovation. For 
example, AS may use the 'realm' parameter in the HTTP Digest AKA 
Authorization header to locate the authenticator. 

3) The Authenticator checks if the AS is authorized to do HTTP re-direction and 
request a new HTTP Digest AKA password for this UE. If yes, then the 

Authenticator takes the identity information from the request (typically for the URI 
parameter), and encodes this information again to the HTTP Digest AKA challenge 

(most likely the Authenticator puts the identity information to the so-called "server 

data" of HTTP Digest AKA nonce, as described in RFC 3310). 
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Note: By including the identity to the challenge, the Authenticator can be sure 
that the identity of the AS Of the temporary identity of the end-user cannot be 
changed by any party (such as an attacker) between the UB and Authenticator 
becanse the challenge la returned back to the Authenticator in the next message. 

5 4) The UE authenticates the network (as defined in standard AKA protocol) and 
generates a new password based on HTTP Digest AKA challenge. The UE stores 
locally the identity of the AS and the newly generated password to be used later for 
mutual authentication with the AS. If the challenge included also a new temporary 
'usemams' to the AS, the usemame is also stored with the password and the AS 
10 identity. Both the AS and UE identities are encoded in the HTTP Digest AKA 

challenge, *e.g using the format <fc useoiame@ realm". UE sends the authentication 
response to the Authenticator. 

Note: The UE should mark the potential new 'username 8 as temporary username. 
This username and related HTTP Digest AKA password should be removed when 
15 new potential 'username* and password are generated for the same realm. If the 

challenge does not include new temporary username, then the existing username 
should be re-used 

5) The Authenticator authenticates the UB, and if successful, stores the new password 
and the identities of the UE and the AS to be used later. The request is redirected 
20 back to the AS. 

What happens next is up to the implementation. If appropriate, the AS may trast on the 
initial authentication performed fay the Authenticator. If not perceived secure, the AS 
may also re-challenge the UE now using the newly generated password. This time, 
HTTP Digest AKA is not used for authentication. Instead, HTTP Digest with some 
25 other algorithm is used, e.g. MD5 can be used (see RFC 2617). 

Step lb 

The first phase can also be performed using a different procedure (see figure lb). 
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Figure lb: Password generation and identity agreement 
The procedure has the following steps: 

1) UE sends a HTTP request (typically HTTP GET) to an AS. 

2) Since the AS and the UE do not have a shared secret, the AS requests HTTP Digest 
AKA authentication challenge directly from she Authenticatar. The request may 
include the identity of the AS and the new temporal identity of the end-aser. 

3) The Authenticator checks if the AS is authorized to request a new HTTP Digest 
AKA password for this HE. If yes, then the Authenticator takes the identity of the 
AS and the temporal identity of the end-user (if present) from the request, and 
encodes this information to the HTTP Digest AKA challenge as in Figure la. 
Alternatively, the AS may also include this information to the challenge in step 4. 
Identity information is encoded in some standard format, e.g. usemame® realm. 
Information needed by the AS to create HTTP Digest AKA challenge are sent back 
to the AS. If these parameters include the HTTP Digest AKA password, then 
process steps 6) and 7) may not be needed. 

4) The UE is challenged by HTTP Digest AKA authentication challenge. The AS may 
add the identity information (both the AS and end-user identities) to the 
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authentication challenge before sending the challenge to the UE. However, in this 
case, the AS must be the end-point for the authentication, and possess the HTTP 
Digest ASIA password, 

5) The UE authenticates the network (as defined in standard AKA protocol) and 
5 generates a new password based on HTTP Digest AKA challenge. The UE stores 

locally the identity of the AS (e.g. the "realm"), the newly generated password, and 
the new temporary "usemame* for Itself to the AS to be used later for mutual 
authentication with the AS - if present in the challenge. UE sends the authentication 
response to the AS, 

10 Note: The UK should mark the potential new 'usemame' as temporary usemame. 

This usemame and related HTTP Digest AKA password should be removed when 
new 'usemame* and password is generated for the same realm. If the challenge does 
not include new temporary usemame. then the existing usemame should be re-usecL 

6) If the AS did not receive the end-user password in step 3), it must .request 
15 Authenticator to do the authentication at this phase. 

VI , 

mV 

7) If the AS did not receive the end-user password in step 3) and it requested 
authentication in step 6, The Authenticates authenticates the UE, and returns the 
appropriate result to the AS, The Authenticator may also send the end-user 
password to AS at this or some later phase. 

20 8) If the UE authentication was successful, the service is delivered to the UE. 
Step 2 

When the AS wants next time to authenticate the UE (which may be directly after the 
previous procedures, or after some longer period of time, e.g. when the UE contacts the 
AS next time), the procedure is as presented in Figure 2. 
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Figure 2: The use of new password. 

6) UB seDds a HTTP request (typically HTTP GET) to an AS. 

7) Since the AS and the UE have now a shared secret, the AS challenges the UE with 
HTTP Digest challenge. The challenge includes the identity of the AS in the 
"realm" parameter. 

8) The UE sends an authentication response (typically in HTTP GET request) back to 
the AS using the new temporary 'username' and password for the AS created during 
the previous phase, If the new temporary username was not created, then the normal 
AKA specific username is used. The UE uses the "realm" parameter to identify the 
correct password. 

9) if the AS possesses the end-user password, steps 9 and 10 are not needed If not, 
then the AS request from the Authenticator (or some other network entity to where 
the Authenticator has stored the UE specific password), for authentication. 

15 10) There are two different modes to proceed: 

a) The Authenticator may talce care of the authentication on behalf of the AS. 
Li this case, the AS does not need to iccow the password, and the 
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Authenticate* returns just mfannation on whether the authentication was 
successful or not 

b) The Authenticates may send the password to the AS, and the AS may 
perform the authentication. 
5 1 1) if the authentication was successful, the AS delivers the service to the UK 
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CLAIMS; 



1 . A method of generating a password for use by an end-user device (HE) to access 
a remote server, comprising: 
5 sanding a request for access from the TIE to the remote server; 

sending to an authentication node in the UE r s home network details of the 
request for access and the identity of the remote server; 

at the authentication node or the remote server, generating a HTTP Digest 
♦ challenge using an algorithm capable of generating end-user passwords, such as HTTP 
10 Digest AKA, including details of the idend ry of the remote server and the identity of the 
UE; 

at the UE, generating a password based on the HTTP Digest challenge, said 
password being associated with the identity of the remote server and the identity of the 
UE; and 

15 storing the password at the UE. 
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ABSTRACT 
Method for Distributing Passwords 

A method of generating a password for use by an end-user device (UE) to access a 
remote server comprises sending a request for access from the UE to the remote server, 
and sending details of the request for access and the identity of the remote server to an 
authentication node in the UE s s home network. The authentication node generates a 
HTTP Digest challenge with algorithm that is able to generate passwords for the UE, 
including details of the identity of the remote server and the identity of the UE in the 
challenge- The UE generates a password based on the HTTP Digest challenge. The 
password is associated with the identity of the remote server and the identity of the UE 
and is stored at the UE, 
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